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Abstract. This paper presents a unified framework for dealing with a deduction system and a denotational 
' semantics of exceptions. It is based on the fact that handling exceptions can be seen as a kind of generalized 

case distinction. This point of view on exceptions has been introduced in 2004, it is based on the notion of 
■ diagrammatic logic, which assumes some familiarity with category theory. Extensive sums of types can be 

(N ■ 

used for dealing with case distinctions. The aim of this new paper is to focus on the role of a generalized 
. extensivity property for dealing with exceptions. Moreover, the presentation of this paper makes only a 

' restricted use of category theory. 
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1 Introduction 

> ■ 

\^ ' This paper presents a unified framework for dealing with a deduction system and a denotational semantics 

Q^ , of exceptions. It is based on the fact that handling exceptions can be seen as a kind of generalized case 

' distinction. This point of view on exceptions has been introduced in [5] , and a short presentation can 

""^J, , be found in [7]. In both these papers, some familiarity with category theory (adjunction, sketches,. . . ) 

lO ' is assumed. One aim of this new paper to present the main ideas of [5] in an elementary way, with a 

i restricted use of category theory. 

■ 

, Usual case distinction can be presented in a distributive logic, which means that products and sums of 

' types are allowed, and that the product is distributive over the sum. Products and sums of types can 

be interpreted as cartesian products and disjoint unions of sets, respectively, so that the distributivity 
property does hold on sets. It follows from 3 that case distinction can also be presented in a weaker 
^ , extensive logic, where sums of types are allowed, and the inverse image of a sum by a function is still 

- - ' a sum. In this paper, exceptions are formalized in a kind of generalized extensive logic; in [6], this 

framework is enriched for dealing also with product types. Exceptions are studied in many different 
frameworks, for instance in [51 [51 [T31 [H El ISl IS] • But, to our knowledge, the emphasize on the use of 
the extensivity property for dealing with exceptions, is new. 

A puzzling issue about exceptions is the apparent discrepancy between the deduction system of a lan- 
guage with exceptions and its set-valued interpretation. Indeed, the type of exceptions is implicit in the 
language, while its interpretation requires an explicit set of exceptions. A major step towards a solution 
is the use of monads in [llj . in the framework of typed lambda-calculus: the functions are classified, on 
the one hand the values are not allowed to raise any exception, on the other hand the computations may 
raise an exception. So, if the types X and Y are interpreted in a set-valued model as the sets A and 
B, then a function f : X —>■ Y is interpreted either as a map if : A B if f is a value, or as a map 
(f : A ^ B + E, where E is the set of exceptional values, if / is a computation. But this approach fails 
to formalize in a satisfactory way the handling of exceptions in the framework of typed lambda-calculus 
[12j . Our approach succeeds in formalizing the handling of exceptions, but the extensive logic is fairly 
different from typed lambda-calculus. Although we do not use monads explicitly, we do distinguish values 
from computations. 
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Actually, three different extensive logics are presented in this paper. The basic extensive logic is described 
in section [3J there are sums of types, and the inverse image of a sum by a function is a sum. This basic 
logic does not deal with exceptions. In the next sections, it is modified in two different ways, in order 
to include a treatment of exceptions. The decorated logic with exceptions, or simply decorated logic, is 
described in section |4l Then the logic with explicit exceptions, or simply explicit logic, is presented in 
section [5l Each of both logics for exceptions has its own deduction system and denotational semantics, 
however the interest of the first one relies primarily in its deduction system, while the denotational 
semantics of the second one is easier to grasp. A link between these logics is established, so that the 
deduction system of the decorated logic is sound with respect to the models in the sense of the explicit 
logic. This solves the problem of the apparent discrepancy between the deduction system of a language 
with exceptions and its set-valued interpretation. 

So, this point of view on exceptions requires a framework for dealing with several logics and the links 
between them. Such a framework is provided by diagrammatic logics [51 13] ■ This work does rely on the 
theory of diagrammatic logics, mainly for the definition of the decorated logic and for the link between 
the decorated logic and the explicit logic, as explained in [6j[7]. However, in this paper, the role of 
diagrammatic logic is hidden, and the few required notions about categories are reminded. Actually, we 
do not need much more than the definition of a category, which is quite simple: it is a directed graph 
where the arrows can be composed as soon as they are consecutive. Proofs can be found in [J. 

A diagrammatic logic is well known as soon as its specifications and theories are carefully described. 
Roughly speaking, a specification is a family of axioms, and a theory is a family of theorems that is closed 
under deduction. The deduction rules of the given diagrammatic logic are used for generating a theory 
from a specification, which means, for deriving theorems from axioms. The models of a specification 
are then defined automatically, in a sound way: every theorem that can be proved from a specification 
is satisfied in every model of the specification, or equivalently, every model of the specification can be 
extended to a model of the generated theory. 

2 About graphs 

In the three logics that will be described, the specifications and theories are some kind of generalized 
graphs and categories, respectively. In this preliminary section, we introduce some basic facts about 
graphs and categories, that will be used in the next sections. 

Definition 2.1 (graph). A (directed multi-)graph is made of points and arrows, that are called respec- 
tively types X, Y ,. . . and (univariate) functions f : X ^ Y ,. . . 

A category is a graph where functions can be composed, with the usual properties of composition, as 
follows. 

Definition 2.2 (category). A category is a graph where each type has an identity function idx : X 
X, each pair of consecutive functions f : X Y and g : Y ^ Z has a composed function g . f : X ^ Z , 
and the unitarity and associativity axioms hold (as soon as it makes sense): 

f.idx = f,±dY.f^f,{h.g).f^h.ig.f). 

As usual, thanks to associativity, parentheses are generally dropped. 

Clearly, each graph generates a category, by adding all the missing identities and composed functions, 
and by identifying some functions according to the axioms. Generating a category from a graph is similar 
to generating all the programs from a grammar of a given language, or generating all the theorems 
about groups (say) from a set of axioms for groups. This is pretty interesting, but far too large: we 



2 



are usually quite happy with some programs and some theorems. . . More is said about this remark in 
the "decomposition theorem" of [S1I3]- About graphs and categories, this remark is the motivation for 
defining something "between" both, as follows. 

Definition 2.3 (compositive graph). A compositive graph is a graph where each type may have a 
(potential) identity function idx : AT — > AT and each pair of consecutive functions f : X Y and 
g : Y Z may have a (potential) composed function g . f : X ^ Z. 

The unitarity and associativity axioms are not mentioned: as any equalities, some of them may hold, 
but this is not mandatory. Typically, a compositive graph may describe a step between a graph and its 
generated category, when some identities and composed functions have been generated. 

The compositive graphs and the categories form the specifications and theories, respectively, of a (very 
simple) diagrammatic logic. The rules of this logic are the identity and composition rules, as well as the 
rules that correspond to the axioms for categories: 

X f-.X^Y g:Y^Z ^ 

(id) (comp) 



±dx:X^X' ' g.f:X^Z 

f -X ->Y f -.X ^Y 

(unit A') T- — J— (unity) 



/.idx-/:X^r ^ idy./ = /:A^r 

J -.X ^Y g:Y Z h : Z ^ T 



{h.g).f^h.{g.f):X^T 



(assoc) 



The fact that types and functions can be considered as symbols that stand for sets and maps, respectively, 
is catched by the following notion of model. In this paper, only set-valued models are considered; a more 
general definition of models can be found in [5l |4]. For clarity, we speak about maps (rather than 
functions) between sets. 

Definition 2.4 (model of a compositive grapii). A (set-valued) model M of a compositive graph 
interprets each type A as a set M{X) and each function / : AT ^ F as a map M{f) : M{X) M{Y), in 
such a way that identity functions are interpreted as identity maps and composed functions as composed 
maps: M (idx) = idM(A) and M {g . f) ^ M{g) . M (/). 

Example 2.5 (natural numbers). Let us consider the graph made of two types Unit and Nat and 
two functions z : Unit Nat and s : Nat — > Nat: 

Unit — ^ Nat^ « 

The generated category contains the functions idunit, idNat, as well as s'^ : Nat Nat and s^ . z : Unit 
Nat for every fc G N. By adding to the initial graph some of these functions, we get a compositive graph. 
The model of naturals of all these graphs interprets Unit as a singleton {*}, Nat as the set N of naturals, 
z as the constant map * 0, which is identified to the element G N, and s as the successor map 
succ : N ^ N. Then the function s*^ . z is interpreted as the constant map * ^ identified to G N. 



There is still a technical point to discuss about compositive graphs and categories. Equality between 
functions is often too crude for dealing with computational issues: for a compiler, functions like / . idx 
and / are distinct, even though they become identified in all models. This is a reason for introducing 
equations f = g as potential equalities in compositive graphs: li f = g, then M(f) — M(g) in every 
model M. So, from now on, every compositive graph may have equations. 

It follows that the categories also have to be modified. An equiv-category looks like a category, except for 
two points. First, it is equipped with equations which form a congruence, which means, an equivalence 
relation compatible with composition. Second, it satisfies the unitarity and associativity axioms only up 
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to congruence. For simplicity, and because this will not cause any trouble in this paper, we still call it a 
category. 

So, this diagrammatic logic is a kind of equational logic, where all functions have arity 1. 

3 A basic logic 

In order to focus on the issue of exceptions, we have chosen a basic logic that deals with case distinctions. 
As in section[51 all its functions have arity 1, since no product of types is provided; multivariate functions 
are considered in [5]. In order to deal with case distinctions, some sums of types are needed, and they 
must satisfy a property called extensivity, after [3] . Note that in [3] the word "extensivity" is used only for 
categories, while here it is used for sums. The specifications and theories of the basic logic are described 
below. 

Definition 3.1 (basic specification). A basic specification E is a compositive graph such that some 
finite lists of types Yi, . . . ,Yn have a (potential) sum, made of a vertex type Yi + . . . + Yn and coprojection 
functions ji : Yi ^ Yi + . . . + Yn, for i £ {1, . . . , n}. 

Definition 3.2 (models of a basic specification). A (set-valued) model of a basic specification is a 
model of the underlying compositive graph that interprets potential sums as disjoint unions. 

The properties of sums in a basic theory are stated now. The first one (existence and unicity of matches) 
is the usual defining property of sums in a category, but only up to congrunce. The second property 
(extensivity of sums) will allow to define case distinction. 

Definition 3.3 (sums and matciies). A sum is a potential sum that satisfies the following property. 
If fi '■ Yi Z, for i e {1, . . . , n}, are functions, then there is a match [ji /i | • . • | jn ^ fn] or 
[/i I ... I /„] ■.Yi + ... + Yn^Z, i.e., a function such that [/i | . . . | /„] . ji = for i e {1, . . . , n}, and if 
/ : Yi + . . . + y„ ^ Z is a function such that f . ji = fi for i G {1, . . . ,n} then / = [/i | . . . | /„] . 

The existence of matches can be illustrated as follows, when n — 2, with dotted arrows for representing 
the coprojections: 



When 71 = 0, a sum "of no type" is called an initial type, denoted 0; it satisfies the following property. 
If Z is a type, then there is a function []z ^ Z such that, if / : ^ Z is a function, then f = []z- 
The existence of empty matches can be illustrated as follows: 



Definition 3.4 (the inverse image of a sum by a function). Let F = Yi + . . . + y„ be a sum, with 
coprojections ji, ■ ■ ■ , jm and let u : X ^ Y he a function. An inverse image of the sum Y ~ Yi-\- . . . -\-Y„ 
by the function m is a sum X = u^^(Yi) + . . . + u^^{Yn), with coprojections u^^(ji), . . . , u^^(j„), together 
with restriction functions Ui : u^^{Yi) — > Yi such that, for i G {1, . . . , n}: 








Z 



ji.Ui =U.U ^{ji) . 
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Here is an illustration when n — 2. 



X " 



... J2 



u-\Y^) ^Y, 



2 



Definition 3.5 (extensivity). A sum F = Yi + . . . + y„ is extensive if, for every function u : X ^Y 
there is an inverse image of the sum Y — Yi + ... + Yn hy the function u, and it is unique (the unicity of 
inverse images, here and in the sequel, is only up to some equivalence). 



Definition 3.6 (basic theories). A basic theory 9 is a basic specification such that its underlying 
graph is a category, and all its potential sums of types are extensive sums. 

The category of sets can be seen as a basic theory, with the equality for congruence. It is not assumed 
here that all sums of types do exist in a basic theory, although this property could be added. Now, case 
distinction in any basic theory is easily defined, thanks to the properties of sums. 

Definition 3.7 (cases). Let Y = Yi + . . . + y„ be a sum, u : X ^ Y a function, and let X = 
u^^{Yi) + . . . + u^^{Yn) be the inverse image. Let fi : u^^{Yi) Z he functions, for z e {1, . . . , n}. The 
case distinction function (or simply the case function) that acts as fi on u~^{Yi), for all i, is: 

case w of [jj /i]i<j<„ = [u~^(jj) /i ]i<j<n : X ^ Z . 




This means that the case function is characterized by the equations: 

(case u of [jj /i]i<i<„) . {u~^{ji)) = fi , for 1 <i <n . 

Clearly, when u = Idy : Y —^ Y, then the case function is congruent to a match: 
(case idy of [ji /i]i<j<„) = [ji => fi]i<i<n : Y ^ Z . 



The basic specifications and the basic theories form a diagrammatic logic, in this paper it is called the 
basic logic. The rules of this logic are the identity and composition rules, as in section [21 together with 
the rules for the existence and unicity of matches and for the extensivity of sums. 

Remark 3.8 (booleans). In order to recover a type of booleans, a sum Bool = F + T can be used. 
Then a function with values in Bool is called a predicate. The inverse image of the sum Bool = F + T by 
a predicate p : X —>■ Bool is also a sum, say X = X}, + Xj-, because of the extensivity property. In the 
basic theory of sets, it can be assumed that the types F and T are interpreted as singletons, so that Bool 
is interpreted as the usual set of booleans. Then, in every model M, the sets M{Xi,) and M(Xj-) are the 
parts of M{X) where the map M{b) is true and false, respectively. 
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Example 3.9 (the basic specification Enat)- The graph in example 12.51 can be considered as a basic 
specification, with no equation and no sum. The rules of the basic logic can be used for deriving, for 
instance, the functions [s ^ s . s \ z ^ z] : Nat — ^ Nat, and (the subscript Nat is omitted): 

p = case idof[s^id|z=^z] = [s=>id|z=>z]: Nat Nat . 

From its definition, the function p satisfies the equations p . z = z and p . s = id. As in example 12.51 
we are interested in the model of naturals of Enat, called Mnat- In this model, the function p must be 
interpreted as the predecessor map pred : N ^ N such that pred(n) ~ n — 1 for each positive n and 
pred(O) = 0. 

4 A decorated logic for exceptions 
4.1 Three keywords for exceptions 

We use the keywords raise for raising exceptions and haindle for handling them, as in Standard ML. 

The predecessor map pred : N — > N from example 13.91 can also be formalised in the following way, if some 
mechanism for exceptions is available: 

First, an exception e is created: 

Exception e 

Then, a function p' : N ^ N is generated, such that p'{z) raises the exception e: 

p'{x) = case X of [s(y) y | z raise e] 

Finally, a function p" : N ^ N is generated, that calls p' and handles the exception e: 

p"{x) = p'{x) handle [e =^ z] 

The basic logic is now modified, in order to be able to deal with the mechanism of exceptions, with its 
three keywords: 

Exception, raise, handle. 

For this purpose, we use a kind of logic where the functions are decorated: each function is associated 
to a symbol, which is called its decoration, and which appears as a superscript. The decorations are 
"w" for value and "c" for computation, they are borrowed from the monads approach [llj . What is new 
here, is that the rules of the logic are also decorated, as will be explained below. In particular, various 
decorations of the extensivity property will give rise to various kinds of case distinctions, which in turn 
will be used for formalizing the treatment of exceptions. We claim that expressions of the form: 

raise e or / handle g , 

can be considered as decorated functions; the keywords "raise" and "handle" are constructors for new 
decorated functions, very much like "[. . .]" and "case" are constructors for new basic functions. Moreover, 
the decoration of every function can be easily derived from the use of the keyword "Exception" and from 
the rules of the decorated logic, as follows: every exception is a computation, and every function involving 
a computation is a computation. 

One issue with the decorated logic is that it does not have set-valued models in such a simple way as 
the basic logic in section [3] or the explicit logic in section [5l which blurs the intuition about this logic. 
In section [5l the decorated logic will be mapped to the explicit logic, and a set-valued interpretation will 
then be recovered. 
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Example 4.1 (the decorated specification Snat.dcco)- In the next examples, a decorated specification 
Snat,dcco IS built progrcssively, so that a predecessor decorated function p is defined in example l4. 21 without 
using exceptions, then a predecessor decorated function p" is defined in example 14.21 with the help of 
exceptions, and finally (also in example 14. 2 p it is proved, in the decorated logic, that p" is congruent to p. 



4.2 The decoration "v" for "value 



The functions that have nothing to do with the exceptions are called values; they are decorated with 
the symbol v, i.e., the notation means that the function / is a value. An equation between values 
is called a value equation, i.e., the notation / g means that /" = is an equation between values. 
The identities are values, and the composition of values is a value. The value equations generate a 
congruence. The sums of types behave as in the basic logic, with values instead of arbitrary functions: 
the coprojections are values, a match of values is a value, and the extensivity property holds for values, 
so that cases over values give rise to values. These sums, matches and cases are denoted as in the basic 
logic, in particular the initial type for values is denoted 0. For the case construction, this means that a 
case like "case u of [ji =^ fi ]i \ where u and the /^'s are values, is the value: 

(case of [j7 => /"]i<j<„)" = (case u of [ ^ /i ]i<i<„)'' = [^"^(ii) ^ /i ]i<i<«'' ■ 

So, one rule of the decorated logic is the extensivity rule for values, which says that every sum has a 
unique inverse image by every value. For binary sums, this rule can be illustrated as follows. 

(" Ui))...- _ 

^1 

X 



Example 4.2 (the value part of Snat.dcco)- In our example, the value part of the decorated specifica- 
tion Snat.deco is & copy of the basic specification Snat from example 13.91 Hence, Enat.deco has two types 
Unit and Nat, two values : Unit Nat and : Nat Nat, and no value equation. It generates a 
value: 

p"" = (case id of [s ^ id I z => z])" = [s ^ id I z ^ z]" : Nat Nat 
so that p . s =" id and p . z z. 



4.3 The decoration "c" for "computation" 

All the functions that may raise exceptions are called computations; they are decorated with the symbol c, 
as well as the equations between them. Since computations may (and not must) raise exceptions, each 
value /" may be coerced into a computation f^, and similarly each value equation may be coerced into 
a computation equation. The composition of computations yields a computation, and the computation 
equations generate a congruence. In the composed computation (g . fY = g'^ ■ f^, it is expected that any 
exception which is raised by is propagated by g^: this is proved in theorem 14.51 

A match of computations is a computation, in a straightforward way. When n = 0, this means that 
the initial type for values is also initial for computations: for every type X, there is a unique value 
[]^ : — > X, and its coercion as a computation is the unique computation [J^^ : — > X. 

Since a match of computations is a computation, a case like "case u of [ji ^ fi]i" is defined when the 
/i's are computations and u is a value; the same notation "case" is used for this construction: 

(case of [j7 /^]i<i<„)^ ^ (case li of [ ^ /i ]i<i<„)^ = [u^^ (ji) ^ ft]i<i<n'' ■ 
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But there is no such definition when u is a computation; indeed, if u raises an exception, there is no 
canonical way to decide which Yi the exception "comes from". However, in section a special situation 
is described, where some kind of "case u'^ of . . ." can be defined, when u is a computation. 

4.4 The keyword Exception 

In a decorated specification, the values are generated from some elementary values, which are the oper- 
ation symbols of a signature, and the computations are generated from some elementary computations, 
which are the exceptions. Recall that a computation /'^ : X — > y in a decorated specification may raise 
an exception instead of returning a result of type Y . Following this idea, we consider that a declaration 
"Exception e of P", for any type P, adds to the decorated specification a computation e"^ : P ^ 0: 
indeed, such a computation cannot return a result of type 0, since stands for the empty set, hence it 
has to raise an exception. 

P 

In this paper, for simplicity, it is assumed that all the exceptions in a decorated specification are given once 
and for all. The exceptions form the coprojections of a new kind of sum in the decorated specification; 
this exceptional sum is studied in section 14.71 

Example 4.3 (the exception of Snat.deco)- In the decorated specification Snat,deco5 the declaration 
"Exception e" adds a computation e'^ : Unit — > 0, from which other computations will be derived in 
example 14.61 

4.5 The keyword raise 

Recall that is an initial type for values and for computations. We claim that when a function f : X ^ Y 
raises an exception e, this means that the exception e can be viewed as an expression of type Y. This is 
expressed in the following definition. 

Definition 4.4 (the keyword raise). The keyword raise is the polymorphic value: 

raisey" = [Jy" : — >Y . 

In a decorated specification S, let e*^ : P ^ be an exception and Y a type. To raise the exception e*^ in 
the type Y is to build the composition: 

(raisey .e)^ : P — >Y . 

The following result proves that the exceptions propagate, as required; it is a consequence of the unicity 
of the empty sum. 

Theorem 4.5 (propagation of exceptions). For every computations f : X ^ and g'^ : Y ^ Z 

(typically, when is an exception) : 

g . raisey . / =" raises . / . 

Example 4.6 (raising an exception in Snat,doco)- In the decorated specification Snat,doco, the com- 
putation p' is defined as follows: 

p'^ = ( case id of [ s => id | z raise . e ] )^ = [ s => id | z ^ raise . : Nat Nat 

It follows from theorem 14.51 that, for every computation g'^ : Nat Nat, the computation {g.p' .zY 
raises the exception e. 
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4.6 The case construction over a computation 



The case construction over a computation, which is described now, can be used only inside a handle 
construction fsection l4.8p . Such a construction occurs only with respect to a sum of the form Y + 0, for 
any type Y. It is easy to prove that the vertex of this sum is isomorphic to with the coprojections 
raises and idy (the subscript Y is often omitted): indeed, the proof involves only values, it is similar 
to the usual proof in the basic logic. This sum Y = Y + may be used as the other sums, for building 
matches of values and matches of computations, and also for building inverse images of values, but this 
has little interest: the inverse image of the sum Y = Y + hy a value : X ^ Y is simply the sum 
X — X + 0. The interesting property of the sum Y = Y + is that there is a special rule for it: this sum 
has an inverse image by every computation u'^ : X —> Y . Indeed, if u raises an exception, then we decide 
that this exception "comes from" the part of the sum Y = Y + 0. More precisely, this inverse image is 
defined below. 



Definition 4.7 (the inverse image of a sum by a computation). Let u'^ : X ^ Y he a computation. 
An inverse image of the sum Y — Y + by the computation u is a sum X — Xu,i + X^fi, with value 
coprojections ^ : X^^i — > X and q ■ ^u.o ~* X , and with a value u\ : X^^i ^ Y and a computation 
Uq : Xufi such that: 

u . ju,i ui and u . ju,a raisey . uq . 



X 



0^,1 ... 



Y 



X. 



M,0 





^'■■■.raise^ 

^0 



Some properties of this inverse image are stated now, their proof is easy. The second one shows that 
there is no ambiguity in our definition: when a computation u'^ comes, by coercion, from a value u", then 
the inverse image of F = F + by the computation u is the same as the inverse image of F = F + by 
the value u. The last property proves the "back-propagation" of the raising of exceptions, with respect 
to values: if u' . u raises an exception, and if it is a value, then u' raises the same exception. 

Proposition 4.8 (properties of the inverse image of a sum by a computation). 

• Let u'^, u' : X — > Y be two computations such that u u' , thenu-^{Y + {)) =u' ^(F + 0). 

• Letu'' : X ^Y be a value, then {u")-^{Y + 0) = X + . 

• Let u'^ : X Y be a computation and u'^ : Y ^ Z a value, then (u'^ . u)~^{Z + 0) = u~^(Y + 0) . 

• Let u'^ : X ^ Y be a computation such that u raisey . / for some computation , then 
(w^)-i(F + 0) = + X . 

• Let u'^ : X ^ Y be a computation and u'^ : Y ^ Z a value, such that u' .u='^ raises . / for some 
computation , then u raisey . /. 

Definition 4.9 (extensivity for computations). A sum F = F + is extensive for computations if, 
for every computation : X ^Y there is an inverse image of the sum F = F + by the computation 
u, and it is unique. 

The rule of extensivity for computations states that in a decorated theory, for every type F the sum 
F = F + is extensive for computations. 
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Definition 4.10 (cases over computations). Let u'^ : X ^ Y he a computation, and : Xu.i Z 
and /q : X^fl — > Z two computations. Then the computation "case"^ li of [ id /i | raise =^ /o]", 
which is cahed a case over computation construction, is defined as: 

( case'^ of [ id ^ /i I raise ^ fo]Y = [ j„,i ^ fi \ jufi ^ foY ■ X ^ Z . 

This means that the case over computation function is characterized by the equations: 
(case'' M of [id ^ /i I raise ^ /o ] . (u^^iji)) = fi , for 1 < z < n . 



4.7 The exceptional case construction 



Let us come back to the declarations of exceptions. The exception declarations "Exception Ci of Pi" , 
for 1 < i < k, add to the decorated specification a sum of a new kind, called the exceptional sum, which 
allows to test which one among the e^'s is some given exception. From now on, let: 

: ^ 0, for 1 < i < fc , 

be the exceptions in some given decorated specification. 

Definition 4.11 (the exceptional sum). The exceptional sum — X)iLi Pi has vertex and copro- 
jections the computations e^'s for 1 < i < fc. 



The exceptional sum is quite special: its coprojections are computations, instead of values, and it is used 
only inside a handle construction (section 148]) . The exceptional sum enjoys a decorated version of only 
one among the properties of sums, namely the extensivity, as follows. 

Definition 4.12 (the inverse image of the exceptional sum by a computation). Let u"^ : X ^ 

be a computation. An inverse image of the exceptional sum by u'^ is a sum X = '^^^(^O' with 

values coprojections {u^^(eiY , together with values u\ : u^^{Pi) Pi such that for each i: 

u . {u^^{ei)) Ci . Ui . 

— -Pi 

""'''^'K-HP^ i '"-- /^ 

Definition 4.13 (extensivity of the exceptional sum). The exceptional sum is extensive if it has a 
unique inverse image by every computation with type 0. 

The rule of extensivity for exceptions states that in a decorated theory, the exceptional sum is extensive. 

Now the exceptional case construction can be defined, as another decorated version of the basic case 
construction. 



Definition 4.14 (exceptional cases). Let : X — > be a computation, / a subset of {1, . . . , fc}, and 
for each i e / let f[ be a computation: 

: u-\P,) ^ Y . 
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For each i ^ /, let be the default computation: 

- (raisey . u . u~\e,)y : u-\P,) ^ Y . 

Then the computation "case^ u of [e^ fi]iei^\ which is caUed an exceptional case construction, is 
defined as: 

{case'' of [ci ^ fi]ieiy = [u'^ie^) ^ f,]i<^<k'' : X ^ Y . 

This means that the computation "case*^ u of [e^ /i]iG/" is characterized by the equations: 

case" u of [e-j => fi]iei ■ "^(eO) = /i i for 1 <i < k . 

Example 4.15 (an exceptional case in Snat.doco)- In the decorated specification Snat,dcco, there is 
only one exception ei — e, so that k — 1 and Pi = Unit, in the exceptional sum. We may consider the 
computations u"^ = e" : Unit and: 

w'^ = case"^ u of [e ^ z] : Unit Nat . 

Then clearly u~^{e) = idunit, so that w'^ z : Unit — > Nat. 

4.8 The keyword handle 

The keyword "handle" has two arguments: for instance, in the function "p' handle [e =^ z]", the 
arguments of handle are p' and [e z]. There are two nested kinds of cases in a handling expression 
"/ handle g" . The first one tests whether / raises an exception, and when this is true, the second one 
tests which is the raised exception. The first one is a case distinction over a computation, as in section l4^ 
and the second one is an exceptional case distinction, as in section [4.71 Now, the handling construction 
is easily defined from these two kinds of cases. 

Definition 4.16 (the keyword handle). Let u'^ : X ^ Y he a computation, and let X — X^^i + X^fi 
be the inverse image of the sum y = y + by the computation u'^, together with the restrictions 
1*5' : Xu,i — > y and Uq : X^ft — > 0. Let X^.o = X^iLi ^(^0 ^^'^ inverse image of the exceptional sum 
by the computation Uq. Let / be a subset of {1, ... , k} and for each i in /, let /f : UQ^{Pi) ^ y be a 
computation. To handle an exception arising from u'^ according to the match [ci ^ fi is to build the 
computation: 

(u handle [ci ^ fi ]ieiY — (case'^ u of [ idy ui \ raisey ^ f]Y : X > Y , 

where / is the computation: 

f = (case'^ Uq of [e^ ^ fi]ieiY ■ ^u,o — > Y . 

The following result proves that the exceptions are handled as required; it can be compared to the rules 
for "handle" in the definition of SML [TO] . 

Theorem 4.17 (properties of the handling of exceptions). 

• Let ui U2 '■ X Y , then (with the above notations) : 

ui handle [e, /i]ie/ U2 handle [e; ^ /i]ie/ • 

• For every value u" : X —>Y : 

u handle [e,; fi\iei u . 
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• For every computation u'^ = raisey .u' : X ^ Y where u''^ : X — > 0; 

u handle [e,; ^ fi\i^i =" case" u' of [e,, ^ f^ . 
If in addition u' — ej . u" : X ^ Y for some j £ {1, . . . ,k} and some value u"^ : X ^ P, then: 

u handle [e^ ^ fj if j E I , 

u handle [e^ ^ fi]iei =^ otherwise . 
Example 4.18 (handling an exception in Snat.doco)- From example \4.2\ p" is the value: 

p" — case idof[s^id|z^2;] = [s=>id|z^z]: Nat Nat . 
On the other hand, from example 14.61 p'^ is the computation: 

p''^ — case id of [ s ^ id I z ^ raise . e ] = [ s => id | 2; => raise . e ] : Nat Nat . 

Now, let: 

p"" = p' handle [e ^ z] : Nat Nat , 
As an example of a proof in the decorated logic, let us prove that p" =" p. 
It follows from the definition of p'" that: 

Nat ^ Nat 

s" 

^ ^ id" 

Nat p" ^ Nat 

_c ^ raise 

' Unit 

e 

Hence, the inverse image of the sum Nat — Nat + by the computation p' is Nat = Nat + Unit, with 
coprojections s and z, and with p'^^ = id and p'q'^ = e. Thus: 

p"^ ~ p' handle \ e ^ z \ =" case" p' of [ id id | raise ^t(;]="[s^id|z^w]: Nat — > Nat , 

where, as in example 14. 151 

w" = case" e of [e z] =" z : Unit Nat . 

It follows that: 

p" ee" [ s =^ id I z ^ z ] : Nat -> Nat . 
Finally, from the unicity of matches, we conclude that: 

V" =V- 

Since p is a value, it follows that the computation p", actually, never raises an exception. 
4.9 Undecoration 

Definition 4.19 (undecoration). The undecoration of a decorated specification Sdcco is the basic 
specification Sbasic that is obtained simply by forgetting the decorations. 
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In the framework of diagrammatic logics, it is easy to check that the undecoration is a morphism from 
the decorated logic to the basic logic. 

By undecoration, every value : X — > 1" or computation : X —^ Y in Sdcco gives rise to a function 
/ : X — s- y in Sbasic- Decorated sums and cases in Sdcco, give rise to ordinary sums and cases in Sbasic- 
The sum X — Xu.i + X^fl gives rise to the sum X — X + Q, and the exceptional sum to a sum with 
vertex 0. Hence, the undecoration allows to get a simplified view on the functions and equations, by 
forgetting all the decorations. It allows to get a simplified view on the proofs, since the image of a proof 
in the decorated logic is a proof in the basic logic. This can be stated as: 

"A proof in Edcco is a proof in Ebasic which can be decorated" . 
This yields a two-step method for checking a proof in the decorated logic: first, the proof without its 
decorations must be valid in the basic logic, then it must be feasible to add the decorations in a way that 
is valid in the decorated logic. 

However, this simplified view "does not preserve the meaning" : for instance, when Unit is interpreted as 
a singleton, a constant exception : Unit — + in Sdeco gives rise in Ebasic to a function e : Unit 0, 
which has no set-valued interpretation. In section[5l the expansion of a decorated specification is defined; 
it is more subtle than the undecoration, and it "does preserve the meaning" . 

Example 4.20 (the undecoration of Snat.dcco)- By undecorating Snat.dcco, we get a basic specification 
Snat, basic, with a fuuctiou 6 : Unit 0, so that this basic specification has no set-valued model where 
Unit is interpreted as a singleton. The computation p"^ in Snat,dccoi that involves the three kinds of 
decorated cases, gives rise in Snat, basic to a function that involves three times the basic case distinction. 

5 A logic with explicit exceptions 
5.1 Expansion 

The exceptions are now considered in an explicit way, which means that there is a type of exceptions E 
which formalizes the set of exceptions, and that E appears in the type of a function, as soon as this 
function may raise an exception. This corresponds to the explicit logic, which has no decorations. It is 
an enrichment of the basic logic with a distinguished type E. 

Definition 5.1 (explicit specification). An explicit specification is a basic specification together with 
a distinguished type E. 

Definition 5.2 (expansion). The expansion of a decorated specification Edcco is the explicit specifi- 
cation Soxpi obtained by adding the distinguished type E, keeping each value f^:X^Yasa function 
f : X ^ Y, and replacing each computation : X ^ Y hy a function f : X ^ Y + E. 

In the framework of diagrammatic logics, it is easy to check that the expansion is a morphism from the 
decorated logic to the explicit logic. 

So, every non-exceptional sum "^^^^iji : Yi ^ Y) in Sdcco gets expanded as a sum J^^^iUi ■ Yi Y) 
in Sexpi- The initial type in Edeco gets expanded as the initial type in Sexpi, and the value raisey = 
[ ]" : — > F gets expanded as [ ] : ^ y, for each type Y. In this way, the properties of sums of values 
in the decorated logic get satisfied by their images in the explicit logic. This includes the existence and 
unicity of the inverse image of any value , which gets expanded as the inverse image of the function u. 
This also includes the property that there are matches of computations; indeed let (/f : Yi — > Z)Ki<n 
be computations in Sdcco, they get expanded as functions (/,; : Yi ^ Z + i?)i<i<ri, and the computation 
[/i I • ■ ■ I fnT - Y ^ Z gets expanded as the function [fi\...\fn]:Y^Z + E. 
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For the cases over computations, let u'^ : X — > 1" be a computation in Sdcco, then the expansion of the 
inverse image of the sum Y = Y + hy the computation u"^ is the inverse image of the sum Y + E hy 
the function u : X Y + E in Scxpi- 

For the exceptional cases, the exceptions e'[ : Pi ^ get expanded as : Pi E. So, the expansion of 
the exceptional sum is the sum E = X)iLi with coprojections the e^'s, and the expansion of an inverse 
image of the exceptional sum is an inverse image of this sum. 

Since the raising and handling of exceptions have been defined in terms of these decorated case construc- 
tions, they get expanded accordingly. 

Example 5.3 (the expansion of Snat.dcco)- Let Snat,expi be the expansion of Snat.doco^ it is made of 
a copy of Snat from example 13.91 together with e : Unit E, which has to be a sum, which means that 
e has to be invertible. 

5.2 Models 

Let Sdcco be a decorated specification, and Eoxpi the explicit specification obtained by expanding Sdoco- 
Let E be a fixed set, called the set of exceptions. A (set-valued) model o/ Ecxpi with set of exceptions E 
is defined as a (set-valued) model (in the basic sense) such that the interpretation of the distinguished 
type E is the set E. So, the exceptions : Pi ^ in Sdcco, that are expanded as Ci : Pi ~* E in Scxpi, 
are interpreted as maps M{ei) : M{Pi) — > E. It follows that E must be the disjoint union of the M{Pi)'s. 

It follows, as required, that the models of the expanded specifications provide a denotational semantics 
for the decorated logic. 

Theorem 5.4 (soundness). The deduction system of the decorated logic is sound with respect to the 
explicit denotational semantics. 

This means that every equation of Sdoco (either between values or between computations) is interpreted 
as an equality in every model of Soxpi- A proof of this result can be found in 6 , it relies upon the 
fact that the decorated and the explicit logics can be formalized as diagrammatic logics, and that the 
expansion is a morphism between them. 

Example 5.5 (the expansion of Snat.dcco)- Let E = {e}. Then Snat.cxpi has a model Mnat.cxpi that 
interprets Unit, Nat, z, and s as {*}, N, and succ, respectively, and e : Unit ^ i? as e : {*} — > E. In 
this model, the computation (raiseNat ■ and the value are interpreted respectively as e and 0. The 
value is interpreted as the predecessor map pred : N ^ N, such that pred(n) = n — 1 for n > and 
pred(O) = 0. The computation p''^ is interpreted as the map pred' : N — > N-l-E, such that pred'(n) = n—1 
for n > and pred'(O) — e. And the computation p"'' is interpreted as the map pred" : N — > N -|- E, such 
that (like pred) prcd"(n) = n — 1 for n > and pred"(0) = 0. 

6 Conclusion 

Two logics for dealing with exceptions are presented in this paper. The decorated logic provides a 
deduction system, and the explicit logic provides a denotational semantics. The expansion, from the 
decorated logic to the explicit logic, ensures soundness. 

Perspectives include the comparison of this approach with other formalizations. Another direction for 
future research is to use a similar approach, via morphisms of diagrammatic logics, in order to study 
other computational effects; in particular, the combination of various effects should run smoothly in our 
diagrammatic framework. 
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